@tenox7 I reproduced #839 from your description and dug into the mechanism — your diagnosis (keepalives during the checksum pass) is right. Two things I found while testing this patch, which I thought were worth passing on:

1. The 5-second interval means it doesn't fix the case in the report. I applied this PR and re-ran a reproducer (single 2 GiB file in a daemon module, ~4.3s to hash):

With --timeout=3 the receiver gives up at 3s, before now - last_checksum_keepalive >= 5 ever fires. Any --timeout below ~6 stays broken.

2. The am_daemon gate is narrower than the bug. It also happens over a remote shell — master fails with --checksum --timeout=2 and --timeout=1 there.

The good news is rsync already has exactly the right primitive: maybe_send_keepalive() self-throttles on allowed_lull, which set_io_timeout() computes as half of --timeout — so it adapts to whatever timeout the user set instead of a fixed 5s, and the generator/sender/receiver already use it for their long stretches.

I've put that up as #1031, with the tick folded into a single loop shared by all six digests (this file has six copies of the same chunk loop, which is why this PR had to patch each one). It's verified digest-identical to master in both directions across the chunk-boundary sizes. Full credit to you for the report and for spotting that keepalives were the answer — please take anything useful from it, or say the word if you'd rather fold the interval change into this PR instead and I'll close mine.